Key management scenarios #34
Conversation
Signed-off-by: marinamoore <[email protected]> Signed-off-by: marinamoore <[email protected]>
Signed-off-by: marinamoore <[email protected]> Signed-off-by: marinamoore <[email protected]>
Signed-off-by: marinamoore <[email protected]>
key-management-scenarios.md
Outdated
| In the event of a compromised or lost key, a developer may need to switch to a new signing key. | ||
| 1. The developer will generate a new signing key. | ||
| 1. The new developer key will need to be added to the delegating party on the registry. | ||
| 1. The previous developer key should no longer be trusted. |
There was a problem hiding this comment.
Does this also mean a developer can't have multiple signing keys?
Currently in notary v1 this is possible.
Comparing this to SSH keys or GPG keys I could potentially use different keys on different systems, which are still linked to the same entity on a server.
Revoking a key is in those cases usually a manual step.
There was a problem hiding this comment.
This is just referring to the single key that was compromised. If a developer has multiple keys, only the compromised key should be revoked. I will re-word to try to clarify this.
key-management-scenarios.md
Outdated
| 1. Create a local environment that delegates to the developer key for testing. | ||
| 1. The developer signs local content. | ||
|
|
||
| ### Scenario #2: A developer is given permission to upload to a registry (for the first time) |
There was a problem hiding this comment.
By "upload to a registry", do you mean push artifact to the registry?
If the answer is yes, the permission has been enforced by the authentication mechanism of registry. I don't think the truest relationship between a registry and a developer needs to be covered in key mgmt scenario.
There was a problem hiding this comment.
Yes, I can switch to that wording if that would be more clear.
I think there are two separate issues here: whether the new developer has permission to push artifacts to the registry and whether the new developer's keys are available and trusted by the registry or registry users. The first issue is certainly out of scope for key management, but I believe the second is something should be addressed by the key management solution.
There was a problem hiding this comment.
Totally agree @mnm678, I see this in a similar fashion as you would verify your SSH private public key pair before getting access to the server.
E.g. lets say my registry credentials got compromised, but the attacker doesn't have my private keys, In that case he won't be able to sign an image as my key is not there. He also won't be able to add his own key as for that he also would require a key more up in the key hierarchie to add his own.
Regarding the wording I think it depends. Current version of notary in theory also supports artifacts beyond the scope of Docker. So if notary v2 will also go that route I think terminology like upload is better and covers things better in general. However if we are entirely focusing on Docker then terminology like push and pull would be better.
Signed-off-by: marinamoore <[email protected]>
|
In general I have one question. Do we need to document some steps in the scenarios regarding the following?
|
|
Why not speaking about the best practice in term of key management which is to use a physical or virtual HSM device ? As an exemple Azure KeyVault is certified HSM fips 140-2 level 2, so it allows to generate signing key, associate a cert to it and let you sign with an API call without never being able to retrieve the key. No one can read the key, including Azure admins. But for information, if you want to buy an Extended Validation (EV) Signing cert, you have to store the key on a fips 140-2 level 2 to be able to buy your cert. That means, you certify that no one, including you, can retrieve the key. |
|
@mnm678 Would you mind closing this PR since no activities for more than 6 months? You can create a new issue to describe the problem if needed. Thanks. |
|
This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 30 days. |
This reopens #23 on the new branch.